Overall package size

Self size: 1.79 MB
Deduped: 2.17 MB
No deduping: 2.17 MB

_{🤖 This report was automatically generated by heaviest-objects-in-the-universe}

Benchmarks

Benchmark execution time: 2026-02-03 17:06:10

Comparing candidate commit e3edd0c in PR branch BridgeAR/2026-02-03-fix-memory-leak with baseline commit 947f5cf in branch main.

Found 0 performance improvements and 1 performance regressions! Performance is the same for 89 metrics, 30 unstable metrics.

scenario:profiler-light-load-with-wall-profiler-22

• 🟥 cpu_user_time [+2.672ms; +10.648ms] or [+2.488%; +9.916%]

👋 @BridgeAR thanks for making this PR - invested onlooker from the linked issue here. Trying to figure out if this will fix things on our app. Could you provide a bit more detail about what the problem was and how it was fixed? Was this only Node 24? Was there a specific commit that caused this to start happening? etc. Thank you!

hey @RDIL, the relevant dd-trace-js commit that enabled this behavior is DataDog/dd-trace-js#7119. It's on by default on Node.js 24+. (It will also be turned on on Node.js 22-23 but only when running Node.js with explicit --experimental-async-context-frame setting.)

If you need a workaround urgently, you can revert to older behavior on Node.js 24+ by setting DD_PROFILING_ASYNC_CONTEXT_FRAME_ENABLED=0 explicitly.

#255 will make this obsolete, as the rework I did there made the freelist not feasible anymore. (FWIW, malloc itself manages a freelist, so I'm not even sure if this measure effectively fought memory fragmentation at all.)

In that PR, I started using Node.js standard ObjectWraps to hold pointers to native objects and they're deleted when their wrapper is GCd in JavaScript. We will also create way fewer native objects, as we need not install a new proxy object anymore every time ACF in CPED changes, but just when we actually change the value of the sample context in an ACF, which in [upcoming counterpart dd-trace-js changes](https://github.com/DataDog/dd-trace-js/tree/szegedi/acf-simple branch) will be just once per span, when it is activated.

Anyhow, we can integrate this PR, I'll just have to add its revert as the first commit to #255.

@szegedi yes, I saw #255, it just seemed like a bigger change that might need more time to actually land and I believe we need something right away.
Would you like me to take a look at 255 (I could do that at the beginning of next week)?